I think if Exclusive ranges were to be kept then special syntax should be added for them, otherwise I think it'd be better to remove them altogether as it's awkward to have syntax for one way but not the other (also doing end - 1 for exclusive ranges isn't too big of a deal at the end of the day).

Also, thoughts on adding unbounded ranges like 3..? I find them pretty useful in other languages that have them for slicing and whatnot (this would also allow the various slice functions to take a Range rather than a second optional argument as discussed in #1566 which seems nicer imo). Range.map could then be replaced with a generator function instead of returning a list to accommodate for not being able to create an infinite list (or an exception could just be thrown in this case 🤷 )

I've updated this PR to turn Range into record Range<a> { range_start: a, range_end: a } as we discussed on the community call. It is now up to APIs to decide if the range is interpreted as Inclusive or Exclusive, and is no longer limited to only Numbers, which also allow APIs to decide how to interpret the types.

Should the casing of the record fields be changed to camelcase to match the rest of the language?

Probably, but I hate it. 🤣

What about just start and end? Since Range will become a builtin type then maybe the range prefix can just be omitted by the same logic that Some is not called OptionSome, Ok is not called ResultOk, etc?

We discussed start and end but it's not a good idea to use commonly used words in records provided by the compiler because they will result in ambiguous record warnings when people write custom records with those common words.

Thoughts on Inclusive and Exclusive submodules (or just an inclusive submodule)? I feel like it'd be pretty nice to be able to do Range.Inclusive.inRange() in those times I want an inclusive range.

just an inclusive submodule

I like the idea. I suppose I need to go back and get that implementation 😛